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5 SYSTEM AND METHOD FOR PROVIDING SELF-INSTALLING 

SOFTWARE COMPONENTS FOR NETWORK SERVICE EXECUTION 

Field 

This application relates in general to software component installation and, 
in particular, to a system and method for providing self-installing software 
10 components for network service execution. 

Background 

With the widespread acceptance of the Internet as a communications and 
data exchange medium, a wide range of network services have become 
increasingly available. Network services refer to a class of host-based services 

15 that can be accessed across a network, including the Internet, to provide 

distributed or remote functionality, such as file services, Web applications and so 
forth. Generally, individual users access network services from a requesting 
system, often termed a client system, remotely interfaced to a service host system 
that executes the network service on behalf of the requesting system. 

20 The use of a network service is distinct from the execution of that network 

service. Service host systems provide network service functionality to requesting 
client systems. However, each client system must first install the network service 
to provide the same network service functionality locally. For example, Web logs 
provide on-line diaries that are centrally hosted and are publicly-accessible by 

25 client systems. To run a local Web log on a client system, a user would first have 
to install the software necessary to run the network service. 

Unfortunately, the end-to-end process of network services software 
installation is also an activity orthogonal to the use of the network service itself. 
A typical software installation requires the user to successfully complete several 

30 sets of independent but related activities. First, the user must know that 
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installation software is required. One difficulty is that the name, type and nature 
of such software may not be rieadily apparent based on the network services. As 
well, suitable installation software might be available in different types and forms. 
Second, the user must obtain a copy of the installation software. 
5 Generally, new application programs, hardware and peripherals either provide the 
installation software with distribution media or through on-line download. 
Obtaining a copy of the installation software for network services, though, can 
potentially present problems. The goal is to install the software necessary to run a 
network service locally, which may incorrectly assume that the user knows where 

10 to get the necessary software. The installation software could be an application 
program or might be available through download on-line via a server operating in 
conjunction with or independently from the service host system. Whatever the 
source, the user is required to identify, hunt down and obtain a copy of the 
required installation software. 

15 Third, the user must determine whether any prerequisites necessary to the 

execution of the network service, plus to run the installation software, are met. 
The full set of all software installed on a computer system defines a runtime 
environment against which any new software must first be matched. However, 
the existing software, including the operating system, can differ from computer 

20 system to computer system, including type, version, and patch level, to name just 
a few distinctions. Each distinction must first be considered prior to installing any 
new software. As a result, the user can proceed with the installation only after 
first satisfying any prerequisites, which can include repeating the previous steps 
of knowing that further installation software is required and getting copies. 

25 Finally, during and possibly following installation, the user may need to 

check whether the software requires updating. Updating software can be tedious 
if support is provided separately from the source from which the copy of the 
software was obtained. In addition, updates might be available in alternative 
forms relative to the installation software, such as being provided only on-line. 

30 Conventionally, installation software and updates are made available as 

resources separate from the network service. On-line updates are becoming 
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increasingly available, such as provided through the Windows Update 
mechanism, provided by Microsoft Corporation, Redmond, WA, the disclosure of 
which is incorporated by reference. However, the mechanism requires the user to 
connect to a Web site, which then evaluates the runtime environment. Based on a 
5 Ust generated by the Web site, the user can select and download updates for 

supported software from a server for local installation. However, the updating is 
performed as an orthogonal process separate from the use of the software. 

Therefore, there is a need for an approach to facilitating software 
installation for executing network services locally by closely associating the 
10 installation software with the network service itself. Preferably, such an approach 
would provide both the installation and network service software together. 

Summary 

An embodiment provides a system and method for providing self- 
installing software components for network service execution. A basic 

15 conmiunication framework is established with a service host system executing a 
network service software component to provide a network service. Availability of 
the network service software component is determined and prerequisites against a 
runtime environnient are verified through the service host system. A code bundle 
providing the network service software component through the service host 

20 system logically grouped with installation instructions for the network service 
software component is executed. 

Still other embodiments of the invention will become readily apparent to 
those skilled in the art from the following detailed description, wherein are 
described embodiments of the invention by way of illustrating the best mode 

25 contemplated for carrying out the invention. As will be realized, the invention is 
capable of other and different embodiments and its several details are capable of 
modifications in various obvious respects, all without departing from the spirit 
and the scope of the invention. Accordingly, the drawings and detailed 
description are to be regarded as illustrative in nature and not as restrictive. 
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Brief Description of the Drawines 

FIGURE 1 is a block diagram showing a system for providing self- 
installing software components for network service execution, in accordance with 
an embodiment. 

5 FIGURE 2 is a functional block diagram showing the service host system 

of FIGURE 1. 

FIGURE 3 is a functional block diagram showing the requesting system of 
nGURE2. 

FIGURE 4 is a data structure diagram showing, by way of example, the 
10 public interface provided to a requesting client by the service host system of 
FIGURE 2. 

FIGURE 5 is a routing diagram showing software installation processing 
and updating in accordance with an embodiment. 

FIGURE 6 is a flow diagram showing a method for providing self- 
15 instaUing software components for network service execution, in accordance with 
an embodiment. . 

FIGURE 7 is a flow diagram showing a routine for determining available 
self-installing software components for use in the routine of FIGURE 6. 

FIGURE 8 is a flow diagram showing a routine for verifying a runtime 
20 environment for use in the routine of FIGURE 6. 

FIGURE 9 is a flow diagram showing a routine for downloading and 
installing self-installing software components for use in the routine of FIGURE 6. . 

FIGURE 10 is a flow diagram; showing a routine for updating self-^ 
installing software components for use in the routine of FIGURE 6. 

25 Detailed Description 

System Overview 

FIGURE 1 is a block diagram showing a system 10 for providing self- 
installing software components for network service execution, in accordance with 

an embodiment. The system 10 includes one or more individual computer 
30 systems 1 1, 12 that can vary in terms of hardware, peripherals, and software 
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components, including operating systems, drivers and support software, network 
and remote services, and applications. In addition, the versions and patch levels 
of the software components can also vary. The computer systems 11, 12 are 
interconnected over a network, such as the Internet. The network 10 can include 
5 local area and wide area networks provided in various topologies, configurations, 
and arrangements of components arranged to interoperatively couple with various 
other networks and include, without limitation, conventionally wired, wireless, 
satellite, optical, and equivalent network technologies, as will be appreciated by 
one skilled in the art. 

10 Software components for executing network services locally are installed 

through Ughtweight, serendipitous interactions between a requesting system 11 
and a service host system 12, as further described below with reference to 
FIGURE 2. Briefly, the service host system 12 is the system hosting the network 
service that a user intends to install and execute locally on the requesting system 

15 11. The requesting system 11 identifies the service host system 12 as a source of 
software necessary to install and execute the network service locally. The 
requesting system 11 confirms that the service host system 12 can provide the 
network service software and, with the assistance of the service host system 12, 
verifies that the runtime environment meets any prerequisites of the network 

20 service software. Upon successful verification, the requesting system 1 1 
downloads and installs the network service software either by requestor 
management or with an installation helper. Following installation, the network 
service software is updated if required. 

Both the requesting system 11 and service host system 12 preferably 

25 execute a managed code platform, such as the Java operating environment, 

licensed by Sun Microsystems, Inc., Palo, Alto, CA, which provides a machine- 
independent and architecture-neutral operating environment. The managed code 
platforms also provide a basic communications framework over which the 
requesting system 11 and the service host system 12 can execute a lightweight 

30 request-and-response protocol through which runtime environment verification. 
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software installation and, if necessary, software updating, can be affected, as 
further described below with reference to FIGURE 5. 

In a further embodiment, one or both of the requesting system 11 and 
service host system 12 directly execute the installation software and network 
5 services as programs written to execute in a specific runtime environment. For 
example, the installation software and network services could be provided as 
platform-specific "native" code designed to run in a particular operating 
environnient, such as the Windows operating environment, licensed by Microsoft 
Corporation, Redmond, WA. Other forms of platform-specific native code, 

10 including declarative code, are possible. 

The individual computer systems, including requesting system 1 1 and 
service host system 12, include general purpose, progranrnied digital computing 
devices including a central processing unit, random access memory, non-volatile 
secondary storage 14, 15, such as a hard drive or CD ROM drive, network or 

15 wireless interfaces, and peripheral devices, including user interfacing means, such 
as a keyboard and display. Program code, including software programs, and data 
is loaded into the RAM for execution and processing by the CPU and results are 
generated for display, output, transmittal, or storage. 

Service Host System 

20 FIGURE 2 is a functional block diagram 20 showing the service host 

system 12 of FIGURE L The service host system 12 executes a network service 
22 that provides distributed or remote functionality to requesting systems 1 1. In 
one embodiment, the service host system 12 executes a managed code platform 
21. The managed code platform 21 can include programming language compilers 

25 and interpreters (not shown) executed by the underlying operating system (not 
shown) to provide a virtual runtime environment within which the network 
service 22 executes. In a further embodiment, the service host system 12 directly 
executes platform-specific applications, including the network service 22. Other 
types of applications or services implemented in software for execution under or 

30 independent of the managed code platform 21 are possible. 
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The service host system 12 provides a standard mechanism for a 
requesting system 1 1 that is a cUent system to download, install and update code 
for providing the equivalent functionality of the network service 22 on that 
requesting system 1 1 locally. The standard mechanism includes a public interface 
5 23 provided by the service host system 12 and a set of well-known methods 24 
invoked through method calls 25 from a requesting system 1 1 on the public 
interface 24, as further described below with reference to FIGURE 4. The 
network service 22 implements the well-known methods 24 to ensure that any 
system requesting a copy of that network service 22 is able to proceed through the 

10 installation and updating processes without having to identify or seek the 

constituent components for the network service software from another source. 
However, the service host system 12 need not function as the source of any 
prerequisite components that may also be needed by a requesting system 1 1. The 
service host system 12 only need assist the requesting system 11 in identifying 

15 whether the prerequisites for the network service 22 are met and could, but need 
not, facilitate satisfying those prerequisites. 

The service host system 12 stores both the software for the network 
service 22 and the installation software as a set of logically grouped components, 
which appear to the requesting system 1 1 as a single unified code bundle. The 

20 actual network service software is stored in a code bundle 28 and the installation 
software is stored in a set of objects 29, which include an installation predicate 
object 30, helper object 31, and update object 32, in a storage 27. 

Requesting Svstem 

FIGURE 3 is a functional block diagram 40 showing the requesting 

25 system 1 1 of FIGURE 2. The requesting system 1 1 sends requests 45 to a service 
host system 12 and receives back responses 26, which can include Boolean values 
44, one or more code bundles 28, and the objects 29. The requesting system 11 
executes a checking mechanism 43 and, optionally, a helper mechanism 43. The 
checking mechanism 42 executes installation predicate objects 30 and update 

30 objects 32 received from the service host system 12. The helper mechanism 43 
executes helper objects 31 also received from the service host system 12. In one 
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embodiment, the requesting system 1 1 executes a managed code platform 41 to 
provide a virtual runtime environment within ^yhich the checking mechanism 42 
and, optionally, the helper mechanism 43 execute. In a further embodiment, the 
service host system 12 directly executes platform-specific applications, including 
5 the checking mechanism 42 and, optionally, the helper mechanism 43. Other 
types of applications or services implemented in software for execution under or 
independent of the managed code platform 41 are possible . 

The requesting system 1 1 installs software components by invoking the 
well-known methods 24 through the public interface 23 provided by the service 

10 host system, as further described below beginning with reference to FIGURE 6. 
The requesting system 1 1 identifies desired installable software, such as an 
network service 22, by locating or serendipitously encountering a requesting 
system 11 upon which the network service software exists. The installable 
software could be either a client or service, depending upon the environment. The 

15 requesting system 1 1 sends an availability request 45 to the service host system 
12 and, if the network service software is available, proceeds to verify the runtime 
environment. The checking mechanism 42 executes an installation predicate 
object 30 to verify that the runtime environment has all the necessary 
prerequisites for installing and running the network service. 

20 In the described embodiment, the installation predicate object 30 is 

implemented as mobile code for execution within the managed code platform 41 
to test any aspect of the requesting system 11, such as hardware, peripherals, and 
software components, including operating systems, drivers and support software, 
network and remote services, and applications, plus the versions and patch levels 

25 of the software components. In a further embodiment, the installation predicate 
object 30 could be implemented in platform-specific native code written using, for 
instance, a declarative syntax specifying a list of required software components 
necessary for the installation to proceed. If the requesting system 1 1 fails to meet 
the prerequisites, the installation predicate object 30 generates a list of required 

30 components, which must be independently satisfied before proceeding further 
with the actual installation. 
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Once all of the prerequisites have been identified, the requesting system 
1 1 sends a code request 45 to the service host system 12 and receives a code 
bundle 28 containing the network service software, which is stored in a storage 46 
as installed code 47. The user must first satisfy any outstanding prerequisites 
5 before manually proceeding with the installation of the network service software. 
Alternatively, the installation steps can be delegated to the helper mechanism 43 
to satisfy any outstanding prerequisites and to perform the installation on behalf 
of the user. If delegated, the helper mechanism 43 executes a helper object 31 to 
locate and obtain copies of any software components necessary to satisfy the 

10 prerequisites. As necessary, the runtime environment is again verified against 
each of the prerequisites. Each of the prerequisites is then installed, followed by 
the installation of the network service software. In the described embodiment, the 
helper object 31 is implemented as mobile code for execution within the managed 
code platform 41. In a further embodiment, the helper object 31 could be 

15 implemented in platform-specific native code written using, for instance, a 
declarative syntax. 

Following successful installation, the requesting system 1 1 sends an 
update request 45 to the service host system 12 and, if required, proceeds to 
update the network service software. The checking mechanism 42 executes an 

20 update object 32 to identify, retrieve and install any necessary updates. In the 
described embodiment, the update object 32 is implemented as mobile code for 
execution within the managed code platform 41. In a further embodiment, the 
update object 32 could be implemented in platform-specific native code written 
using, for instance, a declarative syntax. 

25 Preferably, the requesting system 1 1 persistently stores each of the 

received code bundles 28 and objects 29 in the storage 46. Once installed and 
executing, the network service 22, now executing on the requesting system 11, 
will also provide a public interface 23 through which other requesting systems can 
also invoke the well-known methods 24 to download and update the network 

30 service software from the requesting system 11. Thus, for a network service, the 
network service software becomes "viral." Following successful installation and 
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during execution of the network service 22, the requesting system 11 can become 
a service host system 12 capable of providing the network service software to 
other requesting systems 1 1. In a further embodiment, the network service 
installation software is viral. In a still further embodiment, the updating software 
5 is also viral. Other forms of propagation of the network service 22 are possible. 

In the described embodiment, a client requesting system 11 discovers, 
obtains, installs, and updates code that allows the client system to offer a service 
of equivalent functionality to the network service 22 offered by the service host 
system 12, thus, in effect, becoming a service host system 12 itself. In a further 
10 embodiment, the code obtained by the client requesting system 1 1 from the 
service host system 12 could offer different functionality than the functionality 
provided by the service host system 12. For example, the obtained code could 
offer functionality that allows the client system to interact with the service host 
system. Other types of functionality are possible. 

15 Public Interface Data Structure 

FIGURE 4 is a data structure diagram 60 showing, by way of example, the 
public interface 23 provided to a requesting client by the service host system 12 of 
FIGURE 2. Each network service 22 provides a public interface 23 by defining 
the well-known methods 24. In one embodiment, the well-known methods 24 are 

20 standardized method definitions, preferably written in code in accordance with a 
machine-independent programming language, such as a Java progranmiing 
language, for execution within the managed code platform 21 of the service host 
system 12. In a further embodiment, the well-known methods 24 could be written 
in a declarative syntax for execution independent of managed code platforms, 

25 provided, however, that each of the methods can be invoked remotely by a 

requesting system 11. Other forms implementations of well-known methods are 
possible. 

By way of example, the public interface 23 consists of a tag 61 identifying 
the public interface, such as Speakeasy Component, and a set of method 
30 definitions 62 for each of the well-known methods 24. In the described 

embodiment, a set of four method definitions 62 is specified. When invoking 
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each method, the requesting system 11 identifies the runtime environment, 
including operating system, version and patch level, and the name of the network 
service software as input parameters to each of the well-known methods 24. 
The providesServicelnstaller method definition indicates whether the 
5 network service 22 makes available any special facilities that may need to be 
installed on a requesting system 12 for the network service software to be used. 
Special facilities include the executable network service software, as well as any 
constituent or dependent components. The providesServicelnstaller method 
definition specifies returning a Boolean value definitively indicating the 

10 availability or non-availability of the network service 22. 

The verifyClientEnvironment method definition downloads a predicate 
object 30 with which the requesting system 1 1 can evaluate whether the network 
service software can be installed in the runtime environment of the requesting 
system 11. The installation predicate object 30 evaluates the runtime environment 

15 and generates a list of components that are required before the installation of the 
network service software can proceed. 

The getServicelnstaller method definition downloads the actual installable 
code bundle 28, plus a helper object 31 and, optionally, an update object 32 to the 
requesting system 1 1 to install and, if necessary, update the network service 

20 software. The helper object 31 is used to delegate the installation steps to the 
helper mechanism 43. The update object 32 is used to check whether updates to 
the network service software are required. 

Finally, the codeUpdateRequired method definition indicates whether the 
network service software requires updating, such as following successful 

25 installation or on a periodic basis. Using the update object 32, the requesting 
system 1 1 can maintain a registry of version and patch level identifiers for each 
received code bundle 28 and can periodically check with the network service 22 
to determine whether updating is required. The codeUpdateRequired method 
definition specifies accepting a versionDescriptor string argument that provides 

30 information about the client and returning a Boolean value definitively indicating 
update status. 



0323.US,UTL.ap3 



-11- 



• t 

Although described with reference to specific method definitions 62, other 
implementations and types of method definitions and invocations are possible. 
For instance, the well-known methods 24 could be invoked through a single 
method call 25 on the public interface 23 by specifying different parameters 
5 relative to network service availability, environment verification, installable code 
bundle, and updating. Similarly, the well-known methods 24 could be invoked 
through non-object oriented program semantics using inter-process 
communication mechanisms or remote procedural calls. 

Routing Diagram 

10 FIGURE 5 is a routing diagram 70 showing software installation 

processing and updating in accordance with an embodiment. The requesting 
system 1 1 and service host system 12 implement a lightweight request-and- 
response protocol through which runtime environment verification, software 
installation and, if necessary, software updating, is affected. The requesting 

15 system 1 1 conmiunicates with the service host system 12 by invoking the well- 
known methods 24 through the method calls 25 on the public interface 23 of the 
service host system 12. In response, the service host system 12 sends responses 
26, which can include Boolean values 44, one or more code bundles 28, and 
objects 29. 

20 The protocol proceeds in three logically-defined phases. During the first 

phase, environment verification 71, the requesting system 11 invokes the 
providesServicelnstaller method 74 to determine whether the service host system 
12 makes the network service software available and requires any special 
facilities. In response, the service host system 12 returns a Boolean value 75 

25 indicating whether the network service software is available. If the network 

service software is available on the service host system 12, the requesting system 
11 invokes the verifyClientEnvironment method 76 to receive a predicate object 
77 with which to evaluate whether the prerequisites necessary to affecting the 
installation of the network service software are met. As necessary, the requesting 

30 system 1 1 can iteratively or recursively repeat the providesServicelnstaller 
method call 74 and verifyClientEnvironment method 76 on the service host 

0323.US.UTL.ap3 - 12 - 



system 12 or other service host system for each prerequisite until a complete set 
of all prerequisites is built. 

During the second phase, installation 72, the requesting system 1 1 invokes 
a getServicelnstaller method call 78 on the service host system 12 to receive a 
5 code bundle 28, helper object 31 and, if necessary, update object 32 for the 

network service software. As necessary, the requesting system 1 1 can iteratively 
or recursively repeat the getServicelnstaller method call 77 to the service host 
system 12 or other service host system as required to obtain the software 
components necessary to install both the network service software and each of the 

10 prerequisites identified during the environment verification phase 7 1 . 

During the third phase, update 73, the requesting system 1 1 invokes a 
codeUpdateRequired method call 78 to determine whether the network service 
software requires updating. In response, the service host system 12 returns a 
Boolean value 79 indicating whether an update of the network service software is 

15 required. 

Other phases could also be provided, either in addition to or in lieu of the 
three phases 71, 72, 73. For example, environment verification, installation and 
updating could be performed in a one phase with a single request and single 
response exchanged between the requesting system 11 and the service host system 
20 12. In addition, other forms and dialogues of protocols could be used. For 

instance, the requesting system 1 1 could pull necessary network service software 
from a service host system 12 without response processing. 

Method Overview 

FIGURE 6 is a flow diagram showing a method 90 for providing self- 

25 installing software components, through mobile code, in accordance with an 
embodiment. The method 90 is described from the prospective of a requesting 
system 11, which transacts a lightweight request-and-response protocol dialogue 
with a service host system 12. The method 90 is described as a sequence of 
process operations or steps, which can be executed, for instance, by the requesting 

30 system 1 1 of FIGURE 1 or other components 
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The requesting system 1 1 begins by identifying a network service 22 
(block 91) that is a candidate for installation. The requesting system 1 1 then 
attempts to find a service host system 12 from which to obtain the target network 
service 22 by determining whether the necessary components are available from a 
5 candidate service host system 12 (block 92), as further described below with 
reference to FIGURE 7. 

If the components are not found (block 93), the requesting system 11 
attempts to determine whether another service host system 12 has the network 
service software (block 92). Otherwise, if the available components are found on 

10 the candidate service host system 12 (block 93), the requesting system 1 1 

attempts to verify the runtime environment by executing a predicate object 30 to 
generate a list of components required before an installation can proceed (block 
94), as further described below with reference to FIGURE 8. 

If the runtime environment of the requesting system 11 is not verified due 

15 to failing to meet the required prerequisites (block 95), the requesting system 1 1 
needs to satisfy each prerequisite before installing and executing the network 
service 22. In one embodiment, the requesting system 11 attempts to find a 
service host system 12 from which to obtain the prerequisite components (block 
92). The prerequisite components could be provided by the same service host 

20 system 12 from which the network service software will be obtained or could be 
provided by another separate source. If the runtime environment is verified 
successfully (block 95), the requesting system 11 downloads and installs the 
components for the target network service 22 (block 96), as further described 
below with reference to FIGURE 9. In the described embodiment, the installation 

25 process can be managed explicitly by the user, who carries out the individual 
installation steps on the code bundle 28. Alternatively, the installation steps can 
be delegated to a helper object 31, which will find copies of any prerequisite 
software components, verify the runtime environment, and install the target 
network service 22 and any required prerequisites on the requesting system IL 

30 If the download and installation fails (block 97), an error is generated 

(block.98) and the method terminates. Otherwise, if successful (block 97), the 
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software components for the target network service 22 are updated (block 99), as 
further described below with reference to FIGURE 10. In the described 
embodiment, the requesting system 1 1 executes an update object 22, preferably 
periodically as an automated task, to check whether more recent versions or 
5 patches of the target network service 22 are available. Following updating, the 
method terminates. 

Determining Available Components Routine 

FIGURE 7 is a flow diagram showing a routine 1 10 for determining 
available self-installing software components for use in the method 90 of 
10 FIGURE 6. One purpose of the routine is to determine whether self-installing 
software components for network service are available from a candidate service 
host system 12. 

First, the service host system 12 is identified as a candidate source for a 
target network service 22 (block 1 1 1). Once identified, the requesting system 11 
15 requests the availability of the target network service 22 from the candidate 
service host system 12 (block 112) and receives back a response 45 indicating 
such availability or non-availability (block 113). In the described embodiment, 
, the candidate service host system 12 returns a Boolean value definitively 
indicating availability status. The routine then returns. 

20 Verifying Runtime Environment Routine 

FIGURE 8 is a flow diagram showing a routine 120 for verifying a 
runtime environment for use in the method 90 of FIGURE 6. One purpose of this 
routine is to ensure that any prerequisites necessary to the installation and 
execution of the target network service 22 are satisfied. 

25 First, the requesting system 1 1 requests a predicate object 30 from the 

service host system 12, which the requesting system 11 receives back and 
persistently stores (block 122). The requesting system 11 then executes the 
predicate object 30 to verify the runtime environment (block 123). If the runtime 
environment of the requesting system 11 is successfully verified (block 124), the 

30 routine returns. Otherwise, the predicate object 30 generates a list of missing 
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components (block 125), after which the routine returns. In the described 
embodiment, the list of missing components is provided as a set of software 
components and other parameters necessary to the installation of the target 
network service 22. 

5 Downloading and Installing Components Routine 

FIGURE 9 is a flow diagram showing a routine 130 for downloading and 
installing self-installing software components for use in the method 90 of 
FIGURE 6. One purpose of the routine is to download any code bundles 28 
required to install the target network service 22 and, if installation is delegated, to 

10 carry out the installation steps on behalf of the user. 

First, the requesting system 1 1 requests the one or more code bundles 28 
and, implicitly, the helper object 31 and, if required, update object 32, for the 
target network service 22 from the service host system 12 (block 131). The 
requesting system 1 1 receives and persistently stores each code bundle 28 and the 

15 helper object 31 and update object 32 (block 132). If the user chooses to 
manually install the software components, that is, forgoing the use of the 
installation helper (block 133), the routine returns and the user proceeds with 
manually caring out the installation steps. 

Otherwise, if installation has been delegated to the helper mechanism 43 

20 to satisfy any outstanding prerequisites and to perform the installation on behalf 
of the user (block 133), the helper object 31 is retrieved (block 134). Each code 
bundle 28 is then iteratively processed (blocks 135-144) as follows. For each 
code bundle (block 135), if software components are missing, that is, a list of 
missing software components has been generated by the predicate object 30 

25 (block 136), the requesting system 1 1 determines whether the missing software 
components are available from the service host system 12 (block 137), as further 
described above with reference to FIGURE 7. If the components are not available 
from the service host system 12 (block 138), the requesting system 11 attempts to 
find another service host system from which the missing software components 

30 may be available (block 137). Once the missing software components have been 
found (block 138), the requesting system 1 1 verifies the runtime environment of 
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the requesting system 11 to evaluate whether all prerequisites necessary to the 
installation and execution of the target network service 22 are met (block 139), as 
further described above with reference to FIGURE 8. If the runtime environment 
is not verified, that is, the predicate object 30 for the current missing software 
5 component has generated a list of additional missing software components (block 
140), the requesting system 11 again attempts to determine whether the further 
missing software components can be found on the service host system 12 (block 
137). Finally, once all missing software components are available and the 
runtime environment verified (block 140), the software components are installed 
10 (block 141) by executing the installation in steps specified in the predicate object 
30. If the installation was not successful (block 142), an error is generated (block 
143). Otherwise, if the installation is successful (block 142), processing continues 
with each remaining code bundle 28 (block 144), after which the routine returns. 

Updating Components Routine 

15 . FIGURE 10 is a flow diagram showing a routine 150 for updating self- 

installing software components for use in the method 90 of FIGURE 6. One 
purpose of this routine is to determine whether an installed target network service 
22 requires updating following successful installation. 

The update object 32 is retrieved (block 151) and the requesting system 11 

20 requests whether updates are required from the service host system 12 (block 

152). Upon receiving a response 26 from the service host system 12 (block 153), 
if updating is not required (block 154), the routine retums. Otherwise, the 
requesting system 1 1 requests any necessary updates from the service host system 
12 (block 155). The requesting system 1 1 then receives and installs the updates 

25 (blocks 156 and 157, respectively), after which the routine retums. 

In the described embodiment, a client requesting system 11 discovers, 
obtains, installs, and updates code that allows the client system to offer a service 
of equivalent functionality to the network service 22 offered by the service host 
system 12, thus, in effect, becoming a service host system 12 itself. In a further 

30 embodiment, the code obtained by the client requesting system 1 1 from the 

service host system 12 could offer different functionality than the functionality 
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provided by the service host system 12. For example, the obtained code could 
offer functionality that allows the client system to interact with the service host 
system. Other types of functionality are possible. 

While the invention has been particularly shown and described as 
referenced to the embodiments thereof, those skilled in the art will understand that 
the foregoing and other changes in form and detail may be made therein without 
departing from the spirit and scope of the invention. 
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